"XPNET 3.0 Interim Bug Fixes (IBFs) and Enhancements - WAX" SCR # Change Description ----- ------------------ SCR #2956 OSSTCAT - File modification 11SEP2001 11:02 15-NOV-01 OSSTCATE - File modification 11SEP2001 11:05 OSSTCJ2 - File modification 11SEP2001 11:23 OSSTCJ2E - File modification 11SEP2001 11:24 PXAP31 - File modification 27DEC2001 14:05 PXAP31L - File modification 27DEC2001 14:05 PXCN31 - File modification 27DEC2001 14:05 PXCN31L - File modification 27DEC2001 14:05 PXNC31 - File modification 27DEC2001 14:05 PXNC31L - File modification 27DEC2001 14:05 PXSY31 - File modification 27DEC2001 14:05 PXSY31L - File modification 27DEC2001 14:05 PXTC31 - File modification 27DEC2001 14:05 PXTC31L - File modification 27DEC2001 14:05 PREPOSS - File modification 12NOV2001 13:05 WEBGTCAT - File modification 11SEP2001 13:11 XPNTTCAT - File modification 25OCT2001 17:26 Reference: Internal. Symptom: N/A Problem: N/A Change: Added OSS and implementation components of the XPNET Web Application Services product. The PAX* files that were catalogued with scr2917 have been renamed to PX??31 to accommodate a Tomcat version number. Implementation: Refer to the "XPNET Web Application Services Implementation Guide" document for detailed installation and implementation instructions. Dependencies: Must be installed concurrently with a BASE module at least as recent as rel3^ver0^rel47^010810 (scr2941). SCR #2959 ---XPNET 3.0 21-NOV-01 HTTPCEXT - u30http.http01ce HTTPDC - u30http.http01dc HTTPDCOB - u30http.http01dx HTTPDDDL - u30http.http01ds HTTPDTAL - u30http.http01dt HTTPLIB - u30http.http01 HTTPTEXT - u30http.http01te SATETPLO - w11sate.sate01po SATETPLS - w11sate.sate01ps SKELB - rel3^ver0^sutl12^011121 SKELLIST - compressed spooler listing of SKEL code WAPIDC - u30http.wapi02dc WAPIDCOB - u30http.wapi02dx WAPIDDDL - u30http.wapi02ds WAPIDTAL - u30http.wapi02dt ---XPNET Web Application Services (to be installed on XPNET 3.0 subvolume) PXSY31 - /user/sysaci/sysweb/* (WAX 1.1) sate.o w11sate/sate.o (version 02) PXSY31L - listing of above files ---XNLIB 3.0 Native HTTPDDDL - u31http.http01ds WAPIDDDL - u31http.wapi02ds XNCEXT - u31http.http01ce XNDC - u31http.http01dc - u31http.wapi02dc XNDCOB - u31http.http01dx - u31http.wapi02dx XNDTAL - u31http.http01dt - u31http.wapi02dt XNLIB - REL3_VER1_HTTP01_011121 - compiled non-native XNLIBN - REL3_VER1_HTTP01_011121 - native, not relinkable XNLIBR - REL3_VER1_HTTP01_011121 - native, relinkable XNTEXT - u31http.http01te Reference: Internal Symptom: None. Problem: None. Change: Added support for asynchronous communication between Web Application Servlets and any other application process running under XPNET. See the XPNET Web Application Services Application Programming Guide for more details. Implementation: Install the new files listed above to their appropriate location, either to the XPNET or XNLIB subvolume, as indicated. If on a RISC machine, accelerate new XPNET objects (SKELB) as shown in the XPNET.NETAXCL file. If on a RISC machine, accelerate new XNLIB objects (XNLIB) as shown in the XNLIB.XNAXCL file. On the SCRIBE subvolume, verify that the TMPLIN file contains a 'file' statement for the SATETPLO file. Obey TMPLMAKE to rebuild the TMPLNRES and TMPLRES files, and then obey GOINST to rebuild the complete template set. Install the sate.o file into the OSS file space by starting an OSS shell (osh) and performing the commands below, assuming: a) that the XPNET files mentioned above have been restored to $TEST.XPNET in the Guardian file space and that $TEST is not a virtual disk drive b) that the sate.o file is located on the customer system at /user/sysaci/sysweb/sate.o > cd /user/sysaci/sysweb > rm old_sate.o > mv -i sate.o old_sate.o > pax -ruv \ -f /G/test/xpnet/pxsy31 \ -s ',sysaci/sysweb/*,,' \ sysaci/sysweb/sate.o 2>paxout (if Error 3503 is encountered, the pxsy31 file must be moved to a non-virtual disk drive before performing the pax command on it) Make the sate executable object file on the /user/sysaci/sysweb directory: > make.go (rebuilds the sate object file) Copy the sate object file to its runnable location: > mv -i satengine old_sategine (renames old satengine) > cp -p sate satengine Stop and restart any running satengine processes. For SKEL-based application processes which need to use the HTTP_ routines, BIND the HTTPLIB object into those application objects. The appropriate externals file (HTTPCEXT for C and HTTPTEXT for TAL) should be sourced in as needed. HTTPDTAL (for TAL) and HTTPDC (for C) and HTTPDCOB (for COBOL85) contain constants for status codes returned by the HTTP_ routines. WSAPI control vector DDLs are located in the WAPIDTAL, WAPIDC and WAPIDCOB DDL files, though most applications will not need to use these DDLs. For XNLIB-based application processes which need to use the HTTP_ routines, the HTTP_ routines are already bound into the XNLIB* objects. The HTTP_ proc externals can be found in the XNCEXT (for C) and XNTEXT (for TAL) files. XNDC (for C) and XNDTAL (for TAL) and XNDCOB (for COBOL85) files contain constants for status codes returned by the HTTP_ routines. Refer to the XPNET Web Application Services Implementation Guide for detailed information. Dependencies: This new satengine code must use the XNLIBN library release with this SCR. Older versions of the satengine will not run with this new XNLIBN library and this new satengine will not run with older versions of the XNLIBN library. SCR #2962 ---OSS WAX 1.1 21-NOV-01 PAXSYSA - /user/sysaci/sysweb/* (WAX 1.1) sate.o w11sate/sate.o (version 03) PAXSYSAL - listing of above files Reference: Internal Symptom: When retrieving a large image file through the satengine process, the following message (log message number 5) is displayed: Servlet Engine received an invalid request. HTTP function HTTP_GET_HTTP_RESP_RTE_INFO, status=2 (invalid message), status-detail-1=12 (invalid HTTP response), status-detail-2=194. The message is then dropped and no response is sent to the browser/client. Problem: This problem was introduced with SCR 2959. The code was not treating large HTTP responses correctly when checking to see if the HTTP response was to be routed internally within XPNET. Change: Changed the code to handle large responses correctly and send the response back to the client. Implementation: Install the sate.o file into the OSS file space by starting an OSS shell (osh) and performing the commands below, assuming: a) that the XPNET files mentioned above have been restored to $TEST.XPNET in the Guardian file space and that $TEST is not a virtual disk drive b) that the sate.o file is located on the customer system at /user/sysaci/sysweb/sate.o > cd /user/sysaci/sysweb > rm old_sate.o > mv -i sate.o old_sate.o > pax -ruv \ -f /G/test/xpnet/pxsy31 \ -s ',sysaci/sysweb/*,,' \ sysaci/sysweb/sate.o 2>paxout (if Error 3503 is encountered, the pxsy31 file must be moved to a non-virtual disk drive before performing the pax command on it) Make the sate executable object file on the /user/sysaci/sysweb directory: > make.go (rebuilds the sate object file) Copy the sate object file to its runnable location: > mv -i satengine old_sategine (renames old satengine) > cp -p sate satengine Stop and restart any running satengine processes. SCR #2966 ---XPNET 3.0 09-JAN-02 BASE - rel3^ver0^rel50^020102 - rel3^ver0^exec22^020102 - rel3^ver0^nstp14^020109 - rel3^ver0^proc26^020109 - rel3^ver0^oncf^cj12^020112 - rel3^ver0^oncf^oncf08^020112 - rel3^ver0^oncf^sys21^020102 - rel3^ver0^pyld00^020109 - rel3^ver0^http02^020109 GLOBAL - n30glbl.glbl22 - n30glbl.msg07tg - n30glbl.msg07dt WGI - rel3^ver0^wgi04^020328 NETADRD - rel3^ver0^audr09^020314 NETCJRD - rel3^ver0^cjrp06^020201 - rel3^ver0^rlbk11^020112 NCPCOM - rel3^ver0^ncpc28^020112 - rel3^ver0^ncpl28^020112 - rel3^ver0^rlbk11^020112 SVNCPI - rel3^ver0^ncpi23^020112 - rel3^ver0^obj18^020112 - rel3^ver0^rn15^020112 - s30ncpi.netcmd09 - s30ncpi.netrsp06 - s30ncpi.ncprsp06 SVNCS - rel3^ver0^sncs32^020112 - rel3^ver0^ncpl28^020112 SVNCSP - s30sec.nsp12xs - s30sec.tab11xs SVNCSP24 - s30nsec.nsp12xs - s30sec.tab11xs DDLC - s30sddl.sddl12dc DDLCOB - s30sddl.sddl12dx DDLFUP - s30sddl.sddl12dz DDLS - s30sddl.sddl12ds DDLTAL - s30sddl.sddl12dt NETB - n30base.netb07 NETDC - n30glbl.gddl13dc NETDDLS - n30glbl.gddl13ds NETDFUP - n30glbl.gddl13dz NETDTAL - n30glbl.gddl13dt NCPDC - s30ncpi.ncpi15dc NCPDCB74 - s30ncpi.ncpi15dv NCPDCOB - s30ncpi.ncpi15dx NCPDDDL - s30ncpi.ncpi15ds NCPDFUP - s30ncpi.ncpi15dz NCPDTAL - s30ncpi.ncpi15dt NCPDTCL - s30ncpi.ncpi15da NETEC - n30ems.ems13ec NETECOB - n30ems.ems13ex NETEDDL - n30ems.ems13es NETETAL - n30ems.ems13et NETETCL - n30ems.ems13ea NETTPLO - n30ems.ems18po NETTPLS - n30ems.ems18ps NLIB - rel3_ver0_nlib06_020112 NLIBDC - n30nlib.nlib04dc NLIBDCOB - n30nlib.nlib04dx NLIBDDDL - n30nlib.nlib04ds NLIBDTAL - n30nlib.nlib04dt SKELB - rel3^ver0^sutl13^020112 SKELLIST - n30sutl.sutl13tl APPLIBB - u30alib.alib00b APPLIBBC - u30alib.alib00bc APPLAXCL - u30axcl.appl00 HTTPLIB - rel3_ver0_http02_020109 HTTPCEXT - u30http.http02ce HTTPTEXT - u30http.http02te WAPIDC - u30http.wapi03dc WAPIDCOB - u30http.wapi03dx WAPIDDDL - u30http.wapi03ds WAPIDTAL - u30http.wapi03dt ---XNLIB 3.0 HTTPDDDL - u30http.http01ds WAPIDDDL - u30http.wapi03ds XNCEXT - u30http.http02ce - n30nlib.nlib06ce XNDC - u30http.wapi03dc - n30nlib.nlib04dc XNDCOB - u30http.wapi03dx - n30nlib.nlib04dx XNDTAL - u30http.wapi03dt - n30nlib.nlib04dt XNLIB - rel3_ver0_nlib06_020112 - rel3_ver0_http02_020109 XNTEXT - u30http.http02te - n30nlib.nlib06te ---XNLIB 3.0 Native WAPIDDDL - u31http.wapi03ds XNCEXT - u31http.http02ce - n31nlib.nlib04ce XNDC - u31http.wapi03dc - n31nlib.nlib03dc XNDCOB - u31http.wapi03dx - n31nlib.nlib03dx XNDTAL - u31http.wapi03dt - n31nlib.nlib03dt XNLIB - rel3_ver1_nlib04_020112 - rel3_ver1_http02_020109 XNLIBN - rel3_ver1_nlib04_020112 - rel3_ver1_http02_020109 XNLIBR - rel3_ver1_nlib04_020112 - rel3_ver1_http02_020109 XNTEXT - u31http.http02te - n31nlib.nlib04te ---XPNET Web Application Services PXNC31 - /user/tomcatapps/webapps/ncs/* - files for use with Tomcat 3.1 PXNC31L - listing of PXNC31 files PXNC323 - /user/tomcatapps/webapps/ncs/* - files for use with Tomcat 3.2.3 PXNC323L - listing of PXNC323 files PXSY31 - /user/sysaci/sysweb/* (for Tomcat 3.1) - files for use with Tomcat 3.1 - sate.o (w11sate/sate.o, ver 04) PXSY31L - listing of PXSY31 files PXSY323 - /user/sysaci/sysweb/* (for Tomcat 3.2.3) - files for use with Tomcat 3.2.3 - sate.o (w11sate/sate.o, ver 04) PXSY323L - listing of PXSY323 files Reference: Internal Symptom: None. Problem: None. Change: Added Payload Management to XPNET. Changes made with SCR 2917 allowed for the routing of XPNET messages containing additional data referred to as 'payload'. The payload data follows the text area in the XPNET message and holds additional information (e.g. HTTP headers) used by XPNET and, potentially, applications, to process requests and create valid response messages. When payload was originally implemented within XPNET, applications had to understand payload in order to receive a message with payload and create a valid response. With this enhancement, XPNET has the ability to manage the payload portion of the message on behalf of the application. For example, if an HTTP message is to be routed to a non-HTTP-aware process, XPNET can hold the HTTP payload in memory and just forward the content portion of the HTTP message to the application for processing. When XPNET receives the response from the application, it can than re-attach the payload to the message. In the future, as requirements are defined, payload will be enhanced to hold more than just HTTP data. ONCF commands which have been added or altered to support payload management within XPNET: ALTER NODE, PAYLOADPAGES - This command is used to define the number of extended memory pages to be used for payload management within the node. This number of memory pages is actually allocated out of the number of pages defined by the NODE EXTPAGES attribute (i.e. PAYLOADPAGES defines a subset of EXTPAGES). The default value for this attribute is zero (i.e. payload management in the node is turned off). PAYLOADPAGES may be set no higher than 30% of the NODE EXTPAGES attribute. Only set this attribute greater than zero if you know that XPNET must manage payloads on behalf of one or more applications. ALTER NODE, PAYLOADTIMEOUT - The PAYLOADTIMEOUT attribute defines the number of seconds that a payload will be held in memory within XPNET before it is considered to be expired. Expired payloads will be removed from XPNET memory at regular processing intervals. The default value for this attribute is 200 seconds and it may be set as high as 3600 seconds (i.e. 1 hour). CONTROL NODE, RESIZEPAYLOAD - This command is used after altering the NODE PAYLOADPAGES attribute in order to implement the new PAYLOADPAGES value. INFO NODE, DETAIL - Modified to display the new PAYLOADPAGES and PAYLOADTIMEOUT attributes. STATUS NODE, DETAIL - Modified to display: 1) the total number of payload areas currently allocated and reserved for holding payload within the node (may not all be in use at the current time) 2) the current number of payloads being managed by the node 3) the number of extended memory pages currently being used for payload processing 4) the size of the largest payload that has been managed by the node STATISTICS NODE, DETAIL - Modified to display: 1) the number of payloads that have expired since the last RESETSTATS NODE command 2) the maximum number of payloads that have been managed by the node at any one time since the last RESETSTATS NODE command 3) the maximum number of extended memory pages that have been used for managing payloads at any one time since the last RESETSTATS NODE command NETADRD has also been modified so that for messages with payload, it will break out the text portion of the message separately from the payload portion. The payload itself can be viewed by using the PAYLOAD option when running NETADRD. A new HELP facility has also been added (type NETADRD or NETADRD HELP to see the NETADRD syntax and options). Note that XPNET Payload Management does NOT need to be configured within XPNET for applications that accept and process payloads, themselves. In other words, messages can be routed through XPNET with payload without having NODE PAYLOADPAGES set greater than 0. See the XPNET Web Application Services Application Programming Guide for more details on configuring XPNET to manage payloads when processing HTTP messages and other messages with payload. Implementation: Refer to the XPNET Web Application Services Implementation Guide for detailed information. Install the new XPNET 3.0 files and XPNET Web Application Services files (these are all of the non-XNLIB related files) on the XPNET subvolume. To complete the installation of the Web Application Services files, restore the pax files mentioned above to a temporary directory using the OSS pax utility. Restore the files that contain the version of Tomcat your site is using (3.1 or 3.2.3). Copy files which have been modified from the temporary directory to your installation directory and apply site specific changes (i.e. configuration variables in the .vars file). Example, for a customer using Tomcat 3.1: > cd /user/temp /user/temp > pax -rvf /G/system/xpnet/pxsy31 #creates, overwrites /user/temp/sysaci/* /user/temp > cp -p /user/temp/sysaci/ \ /user/sysaci/ /user/temp > pax -rvf /G/system/xpnet/pxnc31 #creates, overwrites /user/temp/ncs/* /user/temp > cp -p /user/temp/ncs/ \ /user/tomcatapps/webapps/ncs/ Once sate.o is installed on the /user/sysaci/sysweb directory, Make the satengine object file (run make.go). To continue the installation of the XPNET files on the (Guardian) XPNET subvolume, edit the new NETB file to uncomment the modules which the user wishes to bind into their NETWORK object file. Use the new NETB file to rebind the network with the new BASE module and, if purchased, the new WGI protocol module. Since SKELB is run as a user library, do the following only after taking appropriate action to avoid library conflicts. If required, bind SKELB with the high-pin migration library by obeying the SKELMLBC BIND obey file and creating a new SKELB. If the customer desires to bind the HTTP library (HTTPLIB) into SKELB, the APPLIBBC and APPLIBB files should be used. Follow the directions in APPLIBB for completing this process. The resulting APPLIB object can be renamed to SKELB if desired. If on a RISC machine, accelerate the objects as shown in the XPNET.NETAXCL file. Stop all the NCPI servers from TACL. Freeze/Stop/Thaw all active SVNCS and SVNCSP servers. Exit all NCPCOMs and restart using the new object. Restart your nodes using the new NETWORK object file. Application processes which use SKELB as a library must be stopped and restarted in order for the new library to take effect. Application processes which bind in SKELB must be re-compiled or re-bound with the new SKELB. If security is enabled, update the approriate NCSP records to allow for the new ALTER NODE attributes, PAYLOADPAGES and PAYLOADTIMEOUT, and the CONTROL NODE, RESIZEPAYLOAD command. Dependencies: The WGI and BASE modules listed above are interdependent. If a customer is using the WGI protocol module the WGI module listed above cannot be bound into a NETWORK object file with a BASE module older than the one listed (rel3^ver0^rel50^020102). Likewise, an older version of WGI cannot be bound with the BASE module listed above. Additionally, if the customer is running the ACI Satengine process (servlet engine) for processing HTTP requests from Web clients and the BASE module listed above is installed in the NETWORK, then the new Satengine listed above must also be installed. SCR #3035 PXAP323 - File modification 02AUG2002 16:13 01-AUG-02 PXAP323L - File modification 02AUG2002 16:13 PXCN323 - File modification 02AUG2002 16:13 PXCN323L - File modification 02AUG2002 16:13 PXNC323 - File modification 02AUG2002 16:13 PXNC323L - File modification 02AUG2002 16:13 PXPW323 - File modification 02AUG2002 16:13 PXPW323L - File modification 02AUG2002 16:13 PXSY323 - File modification 02AUG2002 16:13 PXSY323L - File modification 02AUG2002 16:13 PXTC323 - File modification 02AUG2002 16:13 PXTC323L - File modification 02AUG2002 16:13 Reference: Internal. Symptom: N/A. Problem: N/A. Change: XPNET Web Application Services has been uplifted to provide support for the Jakarta Tomcat 3.2.3 Servlet container. Tomcat 3.2.3 performance has been found to be 40% better than Tomcat 3.1. Implementation: Refer to the "XPNET Web Application Services Implementation Guide" for detailed instructions on installing Tomcat into the XPNET and OSS environments. The directory structure for the contents of the PX* PAX files remains the same. The following things differ from a Tomcat 3.1/ XPNET installation: 1. The format of the server deployment descriptor has changed. The 'server.xml' file in PXCN323 (on tomcatcntl/prod/conf) has been updated to reflect the new format and ACI-specific additions. The recommended migration from Tomcat 3.1 to Tomcat 3.2.3 is to start with the updated 3.2.3 server.xml and forward-fit any customizations that had been applied to the 3.1 server.xml. Most customizations would have been in the area of adding context paths, and the syntax of this has not changed with Tomcat 3.2.3 server.xml. 2. The CLASSPATH environment variable (from the XNCONF OSS-ENV001 entry) needs to be changed. The reference to /user/tomcat/lib/xml.jar needs to be replaced with two new jar files: /user/tomcat/lib/jaxp.jar /user/tomcat/lib/parser.jar Dependencies: None. SCR #3036 PXSY31 - File modification 01AUG2002 15:08 02-AUG-02 PXSY31L - File modification 01AUG2002 15:08 PXSY323 - File modification 02AUG2002 16:13 PXSY323L - File modification 02AUG2002 16:13 Reference: Internal Symptom: N/A. Problem: N/A. Change: Uplift of XPNET Web Application Services Servlet Engine to use HP NonStop Java 3.0, as well as JDBC support for SQL/MX with NonStop Java 2.x and 3.0. Implementation: The files affected by this SCR are: sysaci/sysweb/make.go sysaci/sysweb/Makefile sysaci/sysweb/MakefileMX sysaci/sysweb/.vars To complete the installation of the Web Application Services files, restore the pax files mentioned above to a temporary directory using the OSS pax utility. Restore the files that contain the version of Tomcat your site is using (3.1 or 3.2.3). Apply site-specific changes (e.g., paths specified in the .vars file) to the temporary copies. Copy from the temporary location to the installation location. Example, for a customer using Tomcat 3.1: > cd /user/temp /user/temp > pax -rvf /G/system/xpnet/pxsy31 \ sysaci/sysweb/make.go /user/temp > pax -rvf /G/system/xpnet/pxsy31 \ sysaci/sysweb/Makefile /user/temp > pax -rvf /G/system/xpnet/pxsy31 \ sysaci/sysweb/MakefileMX /user/temp > pax -rvf /G/system/xpnet/pxsy31 \ sysaci/sysweb/.vars #creates, overwrites /user/temp/sysaci/* /user/temp > cp -p /user/temp/sysaci/sysweb/* \ /user/sysaci/sysweb/. Dependencies: None. SCR #3058 PXSY31 - File modification 07OCT2002 11:17 02-OCT-02 - sysaci/sysweb/AciIntraprocess.jar (ver 01) PXSY31L - listing of above files (07OCT2002 11:17) PXSY323 - File modification 07OCT2002 13:52 - sysaci/sysweb/AciIntraprocess.jar (ver 01) PXSY323L - listing of above files (07OCT2002 13:52) Reference: Internal. Symptom: ICE WebGate logs the following event and replies to XPNET with Guardian error 22: yy-mm-dd;hh:mm:ss.mmm \sys.$pro INSESION.nn.Vnn 2906 WSAPI HTTP_RESPONSE CV length of 6 invalid, vector cannot be empty This occurs when ICE 3.3 020405 or newer is being used and the response is exactly the length of the Satellite engine output buffer (30200 bytes). Older versions of ICE do not produce this error. Change: Modified the AciIntraprocess/ByteArrayOutputStream class so it delays flushing the output buffer when it is exactly full. It now waits until more is written to the buffer, or until the the output stream is closed, to flush it. Implementation: In the OSS environment, change to the sysaci/sysweb directory. Rename the current AciIntraprocess.jar and install the new AciIntraprocess.jar. Stop and start all Satellite Engine processes. Dependencies: None. SCR #3079 ---XPNET 3.0 04-DEC-02 BASE - rel3^ver0^rel57^030112 - rel3^ver0^aud06^030112 - rel3^ver0^exec25^030112 - rel3^ver0^gate26^030112 - rel3^ver0^nstp15^030112 - rel3^ver0^oncf^sys22^030112 - rel3^ver0^que16^030114 - n30glbl.glbl27tg WGI - rel3^ver0^wgi07^030112 NETEDDL - n30ems.ems18es NETEC - n30ems.ems18ec NETECOB - n30ems.ems18ex NETETAL - n30ems.ems18et NETETCL - n30ems.ems18ea NETTPLS - n30ems.ems22ps NETTPLO - n30ems.ems22po AUDPRO - rel3_ver0_audp00_030112 AUDPLIST - u30audp.audp00tl AUDPTEXT - u30audp.audp00te AUDPTPLO - u30audp.audp00po AUDPTPLS - u30audp.audp00ps AUDPEDDL - u30audp.audp00es AUDPEC - u30audp.audp00ec AUDPETAL - u30audp.audp00et AUDPETCL - u30audp.audp00ea ---OSS WAX 1.1 (to be installed on XPNET subvolume) PXSY31 - File modification 28FEB2003 15:28 - sysaci/sysweb/sate.o (ver 06) PXSY31L - listing of above files (28FEB2003 15:28) PXSY323 - File modification 28FEB2003 15:55 - sysaci/sysweb/sate.o (ver 06) PXSY323L - listing of above files (28FEB2003 15:55) Reference: Internal. Symptom: The following events may be logged by WGI: Event 6354: Station received an invalid request. HTTP function HTTP_ENV_CB_INIT, status=2 (invalid message), status-detail-1=4 (invalid HTTP data), status-detail-2=134. Event 6355: Station received invalid vector data. Header vector: length , type , data length . The following events may be logged by the Satengine process: Event 0005: Servlet Engine received an invalid request. HTTP function , status= (), status-detail-1= (), status-detail-2=. Problem: None. Change: When the above events are logged, it is an indication that an invalid or unexpected message was received and could not be processed. After the event was logged, the message was dropped. No retrieval of the invalid message was possible. With this change, after the event is logged, the message will be routed to an XPNET internal destination of #DIAG-DEST. The last 5 messages which have been routed to #DIAG-DEST will be retained in an internal queue. There are two methods for retrieving those messages: 1) Turn on NODE auditing (setting appropriate values for all NODE auditing attributes) and then perform one of the following two control commands: CONTROL NODE , SBIT 17 - copies messages from the #DIAG-DEST queue into the current audit file and audits any new #DIAG-DEST messages to the current audit file - this auditing is done in addition to any other auditing being performed in the network CONTROL NODE , SBIT 18 - copies messages from the #DIAG-DEST queue into the current audit file and audits any new #DIAG-DEST messages to the current audit file - this auditing is done to the EXCLUSION of any other auditing in the system (i.e. the #DIAG-DEST messages will be the only messages written to the audit file, no matter what other auditing attributes or SBITS are configured). Note that even though the messages are audited, the last five messages sent to #DIAG-DEST will remain in the internal queue to provided additional assistance for customer-reported problems. 2) Add a process to the network with a service of "DIAG-DEST" configured in the SERVICE attribute or add a process named "DIAG-DEST". This will cause XPNET to route #DIAG-DEST messages to this process. An AUDPRO (NET24-XPNET Audit Process) application object is provided on the XPNET subvolume which can be configured for this process. AUDPRO is a fairly simple application which writes messages it receives to an audit file. It does contain a hook which allows user-modifications for processing these messages. A Spooler listing of the code is provided in the AUDPLIST file. To run this process, configure the process with the following attributes: PROGRAM: $.XPNET.AUDPRO LIBRARY: $.XNLIB.XNLIB STARTUP: DEMAND SERVICE: DIAG-DEST (optional) STARTOPTIONS: When a message is written to the AUDPRO application, it will write the message to the current audit file, opening a new audit file for the message's date when necessary. AUDPRO audit files are created in the location as described below (see AUDPRO-AUDIT-FILE-VOL-SUBVOL LCONF param) and are given the name Ammddnnn where mm = current month, from msg timestamp dd = current day of month, from msg timestamp nnn = file index 000 - 999, for this date If an audit file fills up it will be closed and a new one created. At the end of the day, the last audit file open for that day will be closed. The NETADRD utility can be used to read these audit files. An open audit file must be closed before it can be read (see the "CLOSEFILE" command below). If necessary, audit files can be pre-created with FUP using a command such as: FUP CREATE ,ext ,TYPE U,FORMAT 1,MAXEXTENTS 64 AUDPRO will open a pre-created file if it contains the index of the next file to be used for the current date, if it is empty and not opened by any other application. The following LCONF assign can be configured for the AUDPRO process: AUDPRO-PRIMARY-EMS-COLLECTOR Assigns the name of a primary EMS collector to write events to. Defaults to collector being used by the XPNET node. The following LCONF params can be configured for the AUDPRO process: AUDPRO-AUDIT-FILE-VOL-SUBVOL A volume.subvolume location telling AUDPRO where to place new audit files it creates. The default location is the same subvolume as the network environment file (NEF) for the respective node. AUDPRO-AUDIT-FILE-PAGES The number of pages that AUDPRO is supposed to use when creating new audit files. A maximum of 62580 and minimum of 10 pages can be configured. The default is 50 pages (100K bytes). AUDPRO-AUTO-SHUTDOWN Valid values: "NO" ("YES" is the default) AUDPRO, by default, will automatically shut itself down at the end of the day unless this parameter is configured to turn off auto- shutdown. Invalid values entered in this param will cause auto-shutdown to remain turned on. The AUDPRO process supports several commands which can be delivered to it from NCPCOM/NCS. All commands support the WAIT directive so that command results can be displayed back at the user's terminal instead of through EMS events (e.g. DELIVER PROCESS P1A^AUDPRO, "INFO", WAIT will display the AUDPRO configuration on the NCPCOM/NCS screen). The following commands can be delivered to the AUDPRO process: "CLOSEFILE" (can abbreviate down to "C") Closes the audit file which is currently open and displays status information for that file. "INFO" (can abbreviate down to "I") Displays the AUDPRO configuration, e.g.: Audit File Location = \SYS1.$D0101.PRO1AUDS Audit File Max Pages = 50 Audit File Max Size (bytes) = 102400 EMS Collector = \NONAME.$COL1 Alternate EMS Collector = $0 "STATUS" (can abbreviate down to "S") Displays status information for the last audit file which was used, e.g.: Filename = \SYS1.$D0101.PRO1AUDS.A0106002 Status = OPEN Messages in File = 1 Bytes Used = 552 File Size (bytes) = 102400 Percentage Used = 1% "WARMBOOT" (can abbreviate down to "W") Reads in new configuration from the LCONF and resets the configuration according to those new assign/param values. Implementation: Install the new BASE and WGI files on the XPNET subvol. Rebind the NETWORK object using the NETB file. If on a RISC machine, accelerate the NETWORK object as shown in the XPNET.NETAXCL file. Stop and restart the XPNET node(s). If using NET24-XPNET Web Application Services, perform the following steps to complete the installation of the new Satengine object: 1) Restore the pax files mentioned above to a subvolume on a non-virtual disk volume. 2) Using the OSS pax utility, restore the sate.o object to a temporary directory. Use the PX* file applicable to the version of Tomcat your site is using (3.1 or 3.2.3). Example, for a customer using Tomcat 3.1: > cd /user/temp /user/temp > pax -rvf /G/system/xpnet/pxsy31 \ sysaci/sysweb/sate.o # creates, overwrites /user/temp/sysaci/sysweb/sate.o 3) Copy from the temporary location to the installation location. /user/temp > cp -p /user/temp/sysaci/sysweb/sate.o \ /user/sysaci/sysweb/. 4) Make the sate executable object file: > cd /user/sysaci/sysweb > make.go (rebuilds the sate object file) 5) Copy the sate object file to its runnable location: > mv -i satengine old_sategine (renames old satengine) > cp -p sate satengine 6) Stop and restart any running Satengine processes. In order to view EMS events written out by the AUDPRO application: 1) Install the AUDPTLPS and AUDPTPLO files onto the XPNET subvolume. 2) Modify the SCRIBE.TMPLIN file to point to the AUDPTPLO file. 3) Remake the XPNET templates using SCRIBE.TMPLMAKE. 4) Re-install all EMS templates using the SCRIBE.GOINST macro. If it is desired to use the AUDPRO application for auditing #DIAG-DEST messages, add a process (using the instructions outlined above) to one or more nodes as defined above and configure any desired AUDPRO LCONF assigns/params. The process can be started with a START command or configured with a STARTUP attribute value of DEMAND so that it will only be started when needed. Dependencies: None SCR #3080 ---XPNET 3.0 04-DEC-02 BASE - rel3^ver0^rel57^030112 - rel3^ver0^exec25^030112 - rel3_ver0_http_rel06_030112 - rel3_ver0_http06_030112 - rel3_ver0_http_util05_030112 HTTPDC - u30http.http02dc HTTPDCOB - u30http.http02dx HTTPDDDL - u30http.http02ds HTTPDTAL - u30http.http02dt HTTPLIB - rel3_ver0_http_rel06_030112 - rel3_ver0_http06_030112 - rel3_ver0_http_util05_030112 NETTPLS - n30ems.ems22ps NETTPLO - n30ems.ems22po WGI - rel3^ver0^wgi07^030112 ---XNLIB 3.0 XNDC - u30http.http02dc XNDCOB - u30http.http02dx XNDTAL - u30http.http02dt XNLIB - rel3_ver0_xnlib_rel09_030215 - rel3_ver0_http_rel06_030112 - rel3_ver0_http06_030112 - rel3_ver0_http_util05_030112 ---XNLIB 3.0 Native XNDC - u31http.http02dc XNDCOB - u31http.http02dx XNDTAL - u31http.http02dt XNLIB - rel3_ver1_xnlib_rel12_030112 - rel3_ver1_http06_030112 - rel3_ver1_http_util05_030112 XNLIBN - (same as XNLIB) XNLIBR - (same as XNLIB) ---OSS WAX 1.1 (to be installed on XPNET subvolume) PXSY31 - File modification 28FEB2003 15:28 - sysaci/sysweb/sate.o (ver 06) PXSY31L - listing of above files (28FEB2003 15:28) PXSY323 - File modification 28FEB2003 15:55 - sysaci/sysweb/sate.o (ver 06) PXSY323L - listing of above files (28FEB2003 15:55) SATETPLS - w11sate.sate02ps SATETPLO - w11sate.sate02po Reference: Internal. Symptom: None. Problem: When invalid messages are received by a WGI station or the Satengine process, inadequate event messages are being logged. Change: Modified the event logging within the WGI protocol and the HTTP utilities used by the Satengine so that the status values displayed and logged reveal more information about where the problem was detected in an invalid message. The modified events being logged will also display portions of the message received, including the first 192 bytes of the message and, when applicable, 48 bytes on either side of where the problem was detected. The EMS events which have been modified are 6354 and 6355 within the WGI protocol, and EMS events 5 and 6 for the Satengine process. Implementation: Install the new XPNET 3.0 files (listed above) onto the XPNET subvol. Rebind the NETWORK object using the NETB file. If on a RISC machine, accelerate the NETWORK object as shown in the XPNET.NETAXCL file. Running XPNET nodes must be stopped and restarted for the XPNET changes to be implemented. Install the XNLIB 3.0 files on the XNLIB subvolume. Install the XNLIB 3.0 Native files on the XNLIBN subvolume. Applications running with the XNLIB or XNLIBN libraries must be stopped and restarted to run with the new libraries. Install the new EMS templates for XPNET and, if applicable, the Satengine process onto the XPNET subvolume. Remake the XPNET templates using SCRIBE.TMPLMAKE, and then remake all EMS templates using the SCRIBE.GOINST macro. If using NET24-XPNET Web Application Services, perform the following steps to complete the installation of the new Satengine object: 1) Restore the pax files mentioned above to a subvolume on a non-virtual disk volume. 2) Using the OSS pax utility, restore the sate.o object to a temporary directory. Use the PX* file applicable to the version of Tomcat your site is using (3.1 or 3.2.3). Example, for a customer using Tomcat 3.1: > cd /user/temp /user/temp > pax -rvf /G/system/xpnet/pxsy31 \ sysaci/sysweb/sate.o # creates, overwrites /user/temp/sysaci/sysweb/sate.o 3) Copy from the temporary location to the installation location. /user/temp > cp -p /user/temp/sysaci/sysweb/sate.o \ /user/sysaci/sysweb/. 4) Make the sate executable object file: > cd /user/sysaci/sysweb > make.go (rebuilds the sate object file) 5) Copy the sate object file to its runnable location: > mv -i satengine old_sategine (renames old satengine) > cp -p sate satengine 6) Stop and restart any running Satengine processes. Dependencies: None SCR #3090 ---OSS WAX 1.1 (to be installed on XPNET subvolume) 09-JAN-03 PXSY31 - File modification 28FEB2003 15:28 - sysaci/sysweb/sate.o (ver 06) PXSY31L - listing of above files (28FEB2003 15:28) PXSY323 - File modification 28FEB2003 15:55 - sysaci/sysweb/sate.o (ver 06) PXSY323L - listing of above files (28FEB2003 15:55) Reference: Internal Symptom: Satengine process logs event 4: "Servlet Engine received MESSAGE FAILURE 109 (stale response - attempt to write a msg and the connection doesn't match)." Problem: Stale responses sent to the station cause excessive queueing at the Satengine process when they are failed back from the station. Change: Since the Satengine does not currently have a mechanism for processing failed messages from the station, the disposition field in the XPNET message header in each response will now be set to 1 so that XPNET will log an event and drop the message instead of sending it back to the Satengine for processing. Implementation: If using NET24-XPNET Web Application Services, perform the following steps to complete the installation of the new Satengine object: 1) Restore the pax files mentioned above to a subvolume on a non-virtual disk volume. 2) Using the OSS pax utility, restore the sate.o object to a temporary directory. Use the PX* file applicable to the version of Tomcat your site is using (3.1 or 3.2.3). Example, for a customer using Tomcat 3.1: > cd /user/temp /user/temp > pax -rvf /G/system/xpnet/pxsy31 \ sysaci/sysweb/sate.o # creates, overwrites /user/temp/sysaci/sysweb/sate.o 3) Copy from the temporary location to the installation location. /user/temp > cp -p /user/temp/sysaci/sysweb/sate.o \ /user/sysaci/sysweb/. 4) Make the sate executable object file: > cd /user/sysaci/sysweb > make.go (rebuilds the sate object file) 5) Copy the sate object file to its runnable location: > mv -i satengine old_sategine (renames old satengine) > cp -p sate satengine 6) Stop and restart any running satengine processes. For customers who have concerns that excessive EMS events may be queued in the NODE they should configure the NODE NOM-related attributes (NOMPAGES, NOMTODISK, NOMA, NOMB, NOMC) and attributes related to NOMing normal EMS events (LOGNQAT, LOGNQMT and LOGNQMI) so that excessive EMS events are NOM'd, if necessary. Dependencies: None. SCR #3112 12-JAN-03 ---OSS WAX 1.1 (to be installed on XPNET subvolume) PXSY31 - File modification 28FEB2003 15:28 - sysaci/sysweb/sate.o (ver 06) PXSY31L - listing of above files (28FEB2003 15:28) PXSY323 - File modification 28FEB2003 15:55 - sysaci/sysweb/sate.o (ver 06) PXSY323L - listing of above files (28FEB2003 15:55) Reference: Internal Symptom: The Satengine terminates at initialization when the logger is configured at the node level with the system name. Problem: A call to event_log_init fails when the collector is passed in the network form. Change: Added a call to insure that the collector is always passed with a node name regardless of the form it is in as input. Implementation: Perform the following steps to complete the installation of the new Satengine object: 1) Restore the pax files mentioned above to a subvolume on a non-virtual disk volume. 2) Using the OSS pax utility, restore the sate.o object to a temporary directory. Use the PX* file applicable to the version of Tomcat your site is using (3.1 or 3.2.3). Example, for a customer using Tomcat 3.1: > cd /user/temp /user/temp > pax -rvf /G/system/xpnet/pxsy31 \ sysaci/sysweb/sate.o # creates, overwrites /user/temp/sysaci/sysweb/sate.o 3) Copy from the temporary location to the installation location. /user/temp > cp -p /user/temp/sysaci/sysweb/sate.o \ /user/sysaci/sysweb/. 4) Make the sate executable object file: > cd /user/sysaci/sysweb > make.go (rebuilds the sate object file) 5) Copy the sate object file to its runnable location: > mv -i satengine old_sategine (renames old satengine) > cp -p sate satengine 6) Stop and restart any running Satengine processes. Dependencies: None. SCR #3141 ---OSS WAX 1.1 (to be installed on XPNET subvolume) 07-AUG-03 PXSY31 - File modification 08AUG2003 9:13 - sysaci/sysweb/Makefile16 (ver 02) - sysaci/sysweb/Makefile (ver 03) - sysaci/sysweb/make.go (ver 03) - sysaci/sysweb/.vars (ver 04) PXSY31L - listing of above files (08AUG2003 9:13) PXSY323 - File modification 08AUG2003 9:45 - sysaci/sysweb/Makefile16 (ver 02) - sysaci/sysweb/Makefile (ver 03) - sysaci/sysweb/make.go (ver 03) - sysaci/sysweb/.vars (ver 04) PXSY323L - listing of above files (08AUG2003 9:45) Reference: Internal. Symptom: (1) Various symptoms may be experienced when linking custom libraries when INCLUDE_JDBCMX=no (or blank) in the .vars file. Specifically the satengine appears to link OK, but the satengine process abends when started and event 2119 is logged: Process creation failed, process create error 63 (63). OSS PROCESS_SPAWN_ z^errno is 4022 (A parameter in the param list is invalid or a required param is omitted). (2) The satengine link step fails with the following error when INCLUDE_JDBCMX=yes: NLD: ERROR **** [1144]: NLD is halting due to the following fatal error: The file name 'crtlmain.o' was specified on the command line, but this file does not exist. Problem: (1) The satengine was not getting linked correctly with multiple custom libraries when INCLUDE_JDBCMX=no (or blank). The make file used in this case was Makefile, which was based loosely on the NSJ 1.6 example provided by HP and was not totally compatible with the link procedures required for newer versions of NSJ (2.0 and 3.0). (2) The crtlmain.o object was not being referred to with a correct path in MakefileMX. Change: (1) Changed how we release the make files and how make.go works. Now, if the customer is using NSJ 1.6 and wants to link the satengine, they should use Makefile16 instead of Makefile (i.e. change the make.go file to point to Makefile16 instead of Makefile). MakefileMX, based on the HP example Makefile for NSJ 2.0, was renamed to Makefile and should be used to link sate.o with NSJ 2.0 and 3.0 versions (which are the most current known versions at this time). The INCLUDE_JDBCMX parameter in the .vars file is still used to control whether the JDBCMX library is linked in or not. (2) Modified Makefile (formerly MakefileMX) and the .vars file to provide the correct path for the crtlmain.o object. Implementation: If using NET24-XPNET Web Application Services, perform the following steps to complete the installation of the new Satengine linking files: 1) Restore the pax files mentioned above to a subvolume on a non-virtual disk volume. 2) Using the OSS pax utility, restore the changed files object to a temporary directory. Use the PX* file applicable to the version of Tomcat your site is using (3.1 or 3.2.3). Example, for a customer using Tomcat 3.1: > cd /user/temp /user/temp > pax -rvf /G/system/xpnet/pxsy31 \ sysaci/sysweb # creates, overwrites /user/temp/sysaci/sysweb/* 3) Copy the modified files from the temporary location to the installation location (overwriting files of the same name on the installation directory): /user/temp > cp -p sysaci/sysweb/Makefile16 \ /user/sysaci/sysweb/. /user/temp > cp -p sysaci/sysweb/Makefile \ /user/sysaci/sysweb/. /user/temp > cp -p sysaci/sysweb/make.go \ /user/sysaci/sysweb/. /user/temp > cp -p sysaci/sysweb/.vars \ /user/sysaci/sysweb/. The /user/temp/sysaci directory can be removed with the command: /user/temp > rm -r sysaci 4) Change directory to the installation directory: > cd /user/sysaci/sysweb Rename or remove the MakefileMX file since it is no longer needed: /user/sysaci/sysweb > rm MakefileMX 5) Edit the .vars file and modify it so that the correct parameter lines are uncommented, depending on whether you are linking with NSJ 1.6, 2.0 or 3.0. 6) If you are linking with NSJ 1.6, change the make.go file to reference Makefile16 instead of Makefile. 7) Make the sate executable object file: > make.go (rebuilds the sate object file) 8) Copy the sate object file to its runnable location: > mv -i satengine old_sategine (renames old satengine) > cp -p sate satengine 9) Stop and restart any running Satengine processes. Dependencies: None SCR #3147 ---OSS WAX 1.1 (to be installed on XPNET subvolume) 05-SEP-03 PXSY31 - File modification 10SEP2003 14:34 - sysaci/sysweb/Makefile (ver 04) - sysaci/sysweb/make.go (ver 04) - sysaci/sysweb/.vars (ver 05) PXSY31L - listing of above files (10SEP2003 14:34) PXSY323 - File modification 10SEP2003 14:57 - sysaci/sysweb/Makefile (ver 04) - sysaci/sysweb/make.go (ver 04) - sysaci/sysweb/.vars (ver 05) PXSY323L - listing of above files (10SEP2003 14:57) Reference: Case 368128 Symptom: Various, resulting from inflexibility and/or incompleteness of current .vars and Makefile layout. Problem: The previously released Makefile was not meant to be modified since the .vars file was provided for variables which might need to be modified on users' systems. However, depending on how a user's system was configured, changes would still be required in the Makefile to get a correct build of the Satengine object. Change: Moved all variables from the Makefile to the .vars file. Verified compatibility with NSJ versions 1.6, 2.0, 2.1, 3.0 and 3.1. The variables that will most likely need to be modified have been moved to the top of each section within the .vars file. Implementation: If using NET24-XPNET Web Application Services, perform the following steps to complete the installation of the new Satengine linking files: 1) Restore the pax files mentioned above to a subvolume on a non-virtual disk volume. 2) Using the OSS pax utility, restore the changed files object to a temporary directory. Use the PX* file applicable to the version of Tomcat your site is using (3.1 or 3.2.3). Example, for a customer using Tomcat 3.2.3: > cd /user/temp /user/temp > pax -rvf /G/system/xpnet/pxsy323 \ sysaci/sysweb # creates, overwrites /user/temp/sysaci/sysweb/* 3) Copy the modified files from the temporary location to the installation location (overwriting files of the same name on the installation directory): /user/temp > cp -p sysaci/sysweb/Makefile \ /user/sysaci/sysweb/. /user/temp > cp -p sysaci/sysweb/make.go \ /user/sysaci/sysweb/. /user/temp > cp -p sysaci/sysweb/.vars \ /user/sysaci/sysweb/. If Makefile16 is not currently present, it may also be copied over, though it was not modified with this SCR (it was modified with SCR 3141). The /user/temp/sysaci directory can be removed with the command: /user/temp > rm -r sysaci 4) Change directory to the installation directory: > cd /user/sysaci/sysweb If the MakefileMX file is present, it can be removed (see SCR3141) since it is no longer needed: /user/sysaci/sysweb > rm MakefileMX 5) Edit the .vars file and modify it so that the correct variables are uncommented, depending on whether you are linking with NSJ 1.6, 2.n or 3.n. 6) Make the sate executable object file: > make.go (rebuilds the sate object file) 7) Copy the sate object file to its runnable location: > mv -i satengine old_sategine (renames old satengine) > cp -p sate satengine 8) Stop and restart any running Satengine processes. Dependencies: None SCR #3160 ---OSS WAX 1.1 (to be installed on XPNET subvolume) 17-DEC-03 PXSY31 - File modification 01MAR2004 14:38 sysaci/sysweb/sate.o (ver 07) T0000D45_20FEB04_WAX11_SATE07 PXSY31L - listing of above files (01MAR2004 14:39) PXSY323 - File modification 01MAR2004 14:56 sysaci/sysweb/sate.o (ver 07) T0000D45_20FEB04_WAX11_SATE07 PXSY323L - listing of above files (01MAR2004 14:56) Reference: Case 372785 Symptom: The OSS Satellite Engine hangs when stopped. Problem: The JNI DestroyJavaVM method is called just before the satellite stops. In certain cases, this call does not complete. Change: Removed the DestroyJavaVM call since the satellite is about to stop anyway. Testing shows that servlets are properly destroyed prior to this point, so the DestroyJavaVM call is not necessary. Implementation: If using NET24-XPNET Web Application Services, perform the following steps to complete the installation of the new Satengine object: 1) Restore the pax files mentioned above to a subvolume on a non-virtual disk volume. 2) Using the OSS pax utility, restore the sate.o object to a temporary directory. Use the PX* file applicable to the version of Tomcat your site is using (3.1 or 3.2.3). Example, for a customer using Tomcat 3.1: > cd /user/temp /user/temp > pax -rvf /G/system/xpnet/pxsy31 \ sysaci/sysweb/sate.o # creates, overwrites /user/temp/sysaci/sysweb/sate.o 3) Copy from the temporary location to the installation location. /user/temp > cp -p /user/temp/sysaci/sysweb/sate.o \ /user/sysaci/sysweb/. 4) Make the sate executable object file: > cd /user/sysaci/sysweb > make.go (rebuilds the sate object file) 5) Copy the sate object file to its runnable location: > mv -i satengine old_sategine (renames old satengine) > cp -p sate satengine 6) Stop and restart any running satengine processes. Dependencies: None. SCR #3168 ---OSS WAX 1.1 (to be installed on XPNET subvolume) 20-FEB-04 PXSY31 - File modification 01MAR2004 14:38 - sysaci/sysweb/sate.o (ver 07) T0000D45_20FEB04_WAX11_SATE07 PXSY31L - listing of above files (01MAR2004 14:39) PXSY323 - File modification 01MAR2004 14:56 - sysaci/sysweb/sate.o (ver 07) T0000D45_20FEB04_WAX11_SATE07 PXSY323L - listing of above files (01MAR2004 14:56) SATETPLS - w11sate.sate03ps SATETPLO - w11sate.sate03po Reference: Case 373983. Symptom: None. Problem: The potential for memory leaks within servlet applications and underlying vendor code has created the need for a way for our users to easily check the heap memory usage of the JVM. Change: Modified the Satengine to support a HEAPSTATUS command which will output the total heap space available and the heap space currently being used. The command can be delivered to any running satengine process in a couple different ways. NCPCOM> DELIVER PRO P1A^SATENGINE, "HEAPSTATUS", WAIT - using this form with the WAIT directive will return the heap status information back to the screen; can be performed from NCS or NCPCOM. NCPCOM> DELIVER PRO P1A^SATENGINE, "HEAPSTATUS" - using this form without the WAIT directive will cause an event to be logged by the satengine process. The satengine process will also check the average heap memory usage at regular intervals and attempt to identify degradation of free memory. If it detects a problem, it will log an event to warn the user. Implementation: Perform the following steps to complete the installation of the new Satengine object: 1) Restore the pax files mentioned above to a subvolume on a non-virtual disk volume. 2) On the SCRIBE subvolume, verify that the TMPLIN file contains a 'file' statement for the SATETPLO file. Obey TMPLMAKE to rebuild the TMPLNRES and TMPLRES files, and then obey GOINST to rebuild the complete template set. 3) Using the OSS pax utility, restore the sate.o object to a temporary directory. Use the PX* file applicable to the version of Tomcat your site is using (3.1 or 3.2.3). Example, for a customer using Tomcat 3.1: > cd /user/temp /user/temp > pax -rvf /G/system/xpnet/pxsy31 \ sysaci/sysweb/sate.o # creates, overwrites /user/temp/sysaci/sysweb/sate.o 4) Copy from the temporary location to the installation location. /user/temp > cp -p /user/temp/sysaci/sysweb/sate.o \ /user/sysaci/sysweb/. 5) Make the sate executable object file: > cd /user/sysaci/sysweb > make.go (rebuilds the sate object file) 6) Copy the sate object file to its runnable location: > mv -i satengine old_sategine (renames old satengine) > cp -p sate satengine 7) Stop and restart any running Satengine processes. Dependencies: None. SCR #3167 XNLIBN.XNLIB - rel3_ver1_xnlib_rel14_040624 19-FEB-04 XNLIBN.XNLIBN - rel3_ver1_xnlib_rel14_040624 XNLIBN.XNLIBR - rel3_ver1_xnlib_rel14_040624 XNLIBN.XNLIBEN - rel3_ver1_xnlib_rel14_040624 XNLIBN.XNLIBER - rel3_ver1_xnlib_rel14_040624 MHDR - rel3_ver1_mdhr06_040624 NLIB - rel3_ver1_nlib08_040624 OSSTCJ4 - last modified 26JUL2004 11:25,eof 28672 OSSTCJ4E - last modified 26JUL2004 11:24,eof 3812 ---OSS WAX 1.1 (to be installed on XPNET subvolume) PXSY31 - last modified 03SEP2004 12:33, eof 260608 sysaci/sysweb/sate.o (ver 08) T0000D45_02MAR04_WAX11_SATE08 sysaci/sysweb/AciIntraprocess.jar (ver 02) 15588 Apr 27 16:53 PXSY31L - listing of above files last modified 03SEP2004 12:33, eof 970 PXSY323 - last modified 03SEP2004 13:15, eof 272896 sysaci/sysweb/sate.o (ver 08) T0000D45_02MAR04_WAX11_SATE08 sysaci/sysweb/AciIntraprocess.jar (ver 02) 15588 Apr 27 16:53 PXSY323L - listing of above files last modified 03SEP2004 13:15, eof 970 ---OSS JMS 1.0 (to be installed on XPNET subvolume) PXJS10 - last modified 19APR2004 15:08, eof 2136576 sysaci/sysjms/lib/acijms.jar (ver 02) 133510 Mar 30 20:31 sysaci/sysutil/lib/xputil.a (ver 01) 123776 Apr 16 14:49 sysaci/sysutil/lib/xputil.jar (ver 02) 143958 Mar 30 19:13 sysaci/sysutil/javadoc/* (ver 02) Apr 19 11:01 PXJS10L - listing of above files last modified 19APR2004 15:09, eof 15873 Reference: Internal. Non Stop Java 4 (NSJ4) support. Several changes to various modules are needed to support NSJ4, all modules must be installed as a unit. NSJ1 note: Support for NSJ1 has been dropped. NSJ2 and NSJ3 notes: NSJ2 and NSJ3 continue to be supported without change. The XONCONF -JavaVmArgs param is required for NSJ2 and NSJ3, the syntax remains unchanged. The Satellite Engine is now built by executing make2.go or make3.go depending on the NSJ version required. The ".vars" file is obsolete, its' contents have been moved into the appropriate make.go file. If the ".vars" file was modified in the past, apply those changes to the appropriate make.go file. Existing Satellite Engine objects need not be rebuilt, but the make files should be modified, if necessary, for future builds. See the Implementation instructions for more. NSJ4 notes: NSJ4 WebApps (Satellite Engine) require the new XNCONF "-JavaVmArgs2" param. See file OSSTCJ4E and item #4 in the "Change" section below for details. Other configuration for NSJ4 applications remains the same as NSJ2 and NSJ3 (with typical changes needed to point to the correct version of java). Any NSJ4 application requiring XNLIB must use the library file named XNLIBEN. This is a new version of XNLIB built for IEEE_FLOAT support. NSJ2 and NSJ3 applications must not use XNLIBEN, they continue to use XNLIBN with TANDEM_FLOAT as in the past. The Satellite Engine for NSJ4 is built by executing make4.go. If customization is needed, edit the make4.go file and modify the appropriate variables. For example, CUSTLIB_DIRS may need to be modified to include native libraries. See the Implementation instructions for more. NOTE- Custom native libraries linked into a NSJ4 JVM must be built with IEEE_FLOAT support if such libraries pass floating point parameters. See the H.P. softdoc for NSJ4 (T3266) for details. Symptom: 1) A JVM that uses NETLIB (XNLIB) to run as a Satellite of XPNET traps for no apparent reason. Impacted applications include the Satellite Engine, JMS JVM's for the Java Device Handler and MobiPay, and the USEC JVM. 2) A JVM that uses XNLIB fails at startup with process create error 66. Impacted applications include the Satellite Engine, JMS JVM's for the Java Device Handler and MobiPay, and the USEC JVM. 3) None. Impacted applications include the Satellite Engine, JMS JVM's for the Java Device Handler and MobiPay, and the USEC JVM. 4) The Satellite Engine terminates saying "Servlet Engine is abnormally terminating (caller 180)" when using NSJ4 or newer. 5) The Satellite Engine logs "java.io.IOException: Stream closed" at java.io.BufferedInputStream ensureOpen(BufferedInputStream.java:) and stops processing. 6) Calls to getLocalHost fail if file /etc/hosts does not exist or the Tandem "Host Name" is not configured in SCF. Response time can also be intermittently delayed when getLocalHost is called. Problem: 1) Signal handling is not allowed with NSJ4. 2) NSJ4 JVM's are built as IEEE_float, so any library used must also be build as IEEE_float. 3) NSJ4 requires IEEE_float, the POW_ routine used by MHDR uses floating point. If we don't change this, the MHDR routines may need to be compiled with IEEE_float creating software management issues. 4) The JNI_GetDefaultJavaVMInitArgs call fails with jstatus of -1 when using NSJ4. That A.P.I. is no longer supported beginning with NSJ4. 5) The Tomcat thread that calls accept on the server socket was not dispatched in time to accept an incoming "connection" (request). This problem did not surface before NSJ4, the possibility of it happening prior to that exists but seems unlikely. 6) Changes in NSJ4 cause getLocalHost problems that did not occur with NSJ3 or earlier. The getLocalHost call also seems to be the underlying cause of the Thread timing problem in #5 above, that problem rarely or never occurred once the getLocalHost call was removed. Change: 1) Added entry point NETLIB_INIT_DONT_HANDLE_TRAPS to the NETLIB module of XNLIB. When this entry point is called, trap handling (signal handling) is not enabled as with NETLIB_INIT. Modified the Satellite Engine (sate.o) and the Netlib Java Native code (xputil.jar) to call the new entry point when NSJ4 or newer is used. The new sate.o and xputil.jar may be used for NSJ2, NSJ3, and NSJ4. When NSJ2 or NSJ3 are used, logic in these modules prevents NETLIB_INIT_DONT_HANDLE_TRAPS from being called, that method is only called when NSJ4 or newer is being used. NSJ2 and NSJ3 modules do not require the new XNLIBN released with this scr, however if it isn't used an undefined external for NETLIB_INIT_DONT_HANDLE_TRAPS will be detected (and can be ignored). 2) Built new XNLIB object files for use with NSJ4. XNLIBEN - Native user library, IEEE_float. XNLIBER - Native relinkable, IEEE_float. NSJ2 and NSJ3 continue to use XNLIBN and XNLIBNR which are built with TANDEM_float as in the past. 3) Renamed the POW_ routine to TEN_TO_POW and changed it so it no longer uses or returns floating point values. This is an internal MHDR (XNLIB) routine that should not be called by the user. Changed MHDR routines that used POW_ to use TEN_TO_POW instead. 4) Added code to support new syntax in the XNCONF for sending arguments to a NSJ4 JVM. The -JavaVmArgs2 argument is now supported and MUST be used for a NSJ4 (or newer) Satellite Engine. Each space separated word within -JavaVmArgs2 is passed unchanged to the JVM as one argument. The syntax for JVM arguments is the same as that specified when running a JVM from the OSH prompt. See file OSSTC4E for an example. The old -JavaVmArgs syntax must be used for NSJ2 and NSJ3. That syntax remains unchanged. Support for NSJ1 is dropped. 5) Changed AciIntraprocess.jar to call Thread.yield in threads that processes requests and responses Those threads are running while the listener thread needs cycles to accept the "next connection", calling Thread.yield should allow the listener thread to run. If an incoming "connection" is received, and the accept thread has still not received the required cycles, the thread that is attempting to complete the accept sleeps for short intervals waiting for accept to be called. 6) Changed AciIntraprocess.jar to call getByName instead of getLocalHost. Besides the call to getLocalHost above, such calls may be caused by application configuration files containing the word "localhost" (i.e. -jndihost localhost). If such configurations cause problems, one or all of the following TCP/IP configuration changes may be needed. If these hints and documentation in the softdoc do not help resolve the problem, contact H.P. support and refer to cases 040210-2304 and 040512-5957. a) If you have a HOSTS file in NSK space, an OSS link to it may be needed in the /etc directory. i.e. /etc/hosts -> /G/system/ztcpip/hosts b) If you have a RESCONF file in NSK space, an OSS link to it may be needed in the /etc directory. i.e. /etc/resolv.conf -> /G/system/ztcpip/recsonf c) The "Host Name" in SCF for the TCP/IP process may need to be configured. Implementation: - - XNLIB 3.1 - - Since XNLIB is run as a user library, do the following only after taking appropriate operator action. Restore the new XNLIB to a Guardian subvolume. Accelerate XNLIB using XNAXCL file. Application processes which bind in XNLIB must be re-compiled or re-bound with the new library. Application processes which use XNLIB as a library must be stopped and restarted in order for the new library to take effect. Take appropriate actions to avoid library conflict errors. - - WAX 1.1 (WebApps) - - If using NET24-XPNET Web Application Services, perform the following steps to complete the installation of this scr. The sample commands are to aid in the discussion, actual commands may vary from site to site and should be executed with caution. This scr and scr3196 are both included in the same version of sate.o (version 08), so scr3196 will also be installed by the following instructions. 1) Restore the PXSY* files mentioned above to the XPNET Guardian subvolume. If the XPNET subvolume is on a virtual disk, copy the PXSY* files to a temporary subvolume on a non-virtual disk and use those in step 2. Files on the current XPNET subvolume named OSSTCAT and OSSTCATE are obsolete and should be purged. These are sample configuration files for NSJ1 which is no longer supported. 2) Create a temporary OSS directory and use the OSS pax utility to restore the PXSY3 file to OSS. Restore the file applicable to the version of Tomcat your site is using (PXSY31 for Tomcat 3.1, PXSY323 for Tomcat 3.2.3). Example for a customer using Tomcat 3.2.3: > mkdir /user/temp > cd /user/temp /user/temp > pax -rvf /G//xpnet/pxsy323 # creates, overwrites /user/temp/sysaci/sysweb/* 3) Copy the following files from the temporary directory to the installation directory. These are files needed to make the executable sate object file. Makefile2, Makefile3, Makefile4, (new files) make2.go, make3.go, make4.go, (new files) sate.o (existing file) For example: > cp -p /user/temp/sysaci/sysweb/Make* \ /user/sysaci/sysweb/. > cp -p /user/temp/sysaci/sysweb/make* \ /user/sysaci/sysweb/. > cp -p /user/temp/sysaci/sysweb/sate.o \ /user/sysaci/sysweb/. AciIntraprocess.jar will be installed in step 9. No changes were made to sysaci/sysweb/tomcat/*, so those files are not re-installed. 4) If needed, customize the make.go file for site specific variables (where = NSJ version). The ".vars" file is obsolete, if it was customized in the past apply those changes to the appropriate make.go file. The Satellite Engine for NSJ4 is built using make4.go. CUSTLIB_DIRS may need to be modified to include native libraries, if such libraries pass floating point parameters they must be built with IEEE_FLOAT support. See the H.P. softdoc for NSJ4 (T3266) for details. 5) The following files are obsolete and should be removed. You may want to copy them to some other directory until new sate objects are made, but they should be REMOVED from this directory to avoid confusion in the future. .vars, make.go, Makefile, Makefile16 Example, to remove the files: > cd /user/sysaci/sysweb > rm .vars > rm make.go > rm Makefile > rm Makefile16 6) Make the sate executable object file. NSJ2 and NSJ3 sate objects do not have to be re-linked, but it is highly recommended (because the make files have changed). They do, however, need to be stopped and started to install the new AciIntraprocess.jar mentioned in step 9. For example: > make4.go (builds an object file named sate) When making NSJ4 objects with make4.go, ignore warnings 10032 and 10034 (inconsistent floattype attributes). 7) Stop all satengine processes. 8) Copy the new sate object from step 6 to its runnable location. For example: > mv -i satengine old_sategine (rename old out) > mv -i sate satengine (rename new in) 9) Replace the installation version of the AciIntraprocess.jar file with the new version from the temporary installation directory (see step #2). For example: > cp -p \ /user/temp/sysaci/sysweb/AciIntraprocess.jar \ /user/sysaci/sysweb/. 10) Start satengine processes. 11) Purge temporary subvolumes and directories created in steps 1 and 2. - - JMS 1.0 - - If you have installed XPNET JMS prior to the date of this scr, and NSJ4 support is required for XPNET JMS, obtain an entire new release from A.C.I. and re-install it according to the "XPNET Java Message Service (JMS) Implementation Guide" (Publication No. XN-NT100-39). Dependencies: None. ---OSS WAX 1.1 (to be installed on XPNET subvolume) SCR #3196 PXSY31 - last modified 03SEP2004 12:33, eof 260608 30-AUG-04 sysaci/sysweb/sate.o (ver 08) T0000D45_02MAR04_WAX11_SATE08 PXSY31L - listing of above files last modified 03SEP2004 12:33, eof 970 PXSY323 - last modified 03SEP2004 13:15, eof 272896 sysaci/sysweb/sate.o (ver 08) T0000D45_02MAR04_WAX11_SATE08 PXSY323L - listing of above files last modified 03SEP2004 13:15, eof 970 Reference: Internal. Symptom: None. Problem: None (enhancement). Change: Allow background threads to run while waiting for messages on $receive in the main thread. This behavior is controlled by arguments -waitinterval and -sleepinterval (similar to our JMS implementation). Waitinterval and sleepinterval are optional arguments, allowing them to default results in behavior that is identical to previous versions of Sate. Argument -waitinterval specifies the time limit for the call to AWAITIOX on $receive. It is specified as milliseconds, but is divided by 10 (truncating the result) to calculate the number of "tics" passed to AWAITIO as the time limit. The default is -1 (wait forever) which causes the Sate to work exactly as in the past. Valid values are greater than or equal to -1. Argument -sleepinterval specifies a number of milliseconds for which the Sate "sleeps" after AWAITIOX completes with a timeout (error 40). Error 40 only occurs if -waitinterval (above) is set to something other than the default of -1. A positive sleepinterval causes the main thread of Sate to sleep for the interval specified, while a value of 0 causes it to yield. This, in combination with waitinterval of other than -1, allows "background" threads in the JVM to run. The default sleepinterval is 100. Valid values are greater than or equal to 0. Certain applications may require background threads to run while the main thread is calling AWATIOX on $receive, such applications require fine tuning of waitinterval and sleepinterval. It is beyond the scope of this document to suggest the proper values for various applications, see application specific documentation for such information. Implementation: This scr and scr3167 are both included in the same version of sate.o (version 08). See the implementation instructions for scr3167, those instructions install this scr also. Dependencies: None. SCR #3210 ---OSS WAX 1.1 (to be installed on XPNET subvolume) 03-DEC-04 PXSY31 - last modified 06DEC2004 15:32, eof 260096 sysaci/sysweb/sate.o (ver 09) T0000D45_03DEC04_WAX11_SATE09 PXSY31L - listing of above files last modified 06DEC2004 15:32, eof 970 PXSY323 - last modified 06DEC2004 15:52, eof 272384 sysaci/sysweb/sate.o (ver 09) T0000D45_03DEC04_WAX11_SATE09 PXSY323L - listing of above files last modified 06DEC2004 15:52, eof 970 Reference: Case 388569. Symptom: If more than 10 system properties (-D params under the -JavaVmArgs argument) are specified, "usage" displays in STDOUT and the Satellite Engine terminates. Problem: The limit of 10 is too small. There was also a problem because the limit check allowed an 11th to be specified when the intended limit was actually 10. Change: Changed the limit of system properties to 50, and fixed the problem that allowed one more than the intended limit to be specified. Implementation: If using NET24-XPNET Web Application Services, perform the following steps to complete the installation of this scr. The sample commands are to aid in the discussion, actual commands may vary from site to site and should be executed with caution. 1) Restore the PXSY* files mentioned above to the XPNET Guardian subvolume. If the XPNET subvolume is on a virtual disk, copy the PXSY* files to a temporary subvolume on a non-virtual disk and use those in step 2. 2) Create a temporary OSS directory and use the OSS pax utility to restore the PXSY3 file to OSS. Restore the file applicable to the version of Tomcat your site is using (PXSY31 for Tomcat 3.1, PXSY323 for Tomcat 3.2.3). Example for a customer using Tomcat 3.2.3: > mkdir /user/temp > cd /user/temp /user/temp > pax -rvf /G//xpnet/pxsy323 # creates, overwrites /user/temp/sysaci/sysweb/* 3) Copy the following files from the temporary directory to the installation directory. Save the existing make?.go files for reference in step 4. make2.go make3.go make4.go sate.o Example (save the old make?.go files): > mkdir /user/sysaci/sysweb/zzold > mv -i /user/sysaci/sysweb/make?.go \ /user/sysaci/sysweb/zzold Example (install the new make?.go and sate.o files): > cp -p /user/temp/sysaci/sysweb/make?.go \ /user/sysaci/sysweb/. > cp -p /user/temp/sysaci/sysweb/sate.o \ /user/sysaci/sysweb/. Other files were not changed, so those files are not re-installed. 4) If needed, customize the make.go file for site specific variables (where = NSJ version). See previous versions of the files saved in step 3 above. 5) Make the sate executable object file. For example: > make4.go (builds an object file named sate) When making NSJ4 objects with make4.go, ignore warnings 10032 and 10034 (inconsistent floattype attributes). 6) Stop all satengine processes. 7) Copy the new sate object from step 5 to its runnable location. For example: > mv -i satengine old_sategine (rename old out) > mv -i sate satengine (rename new in) 8) Start satengine processes. 9) Purge temporary subvolumes and directories created in steps 1, 2, and 3. Dependencies: None. SCR #3245 ---OSS WAX 1.1 (to be installed on XPNET subvolume) 06-MAY-05 PXSY31 - File modification 16MAY2005 16:57 - sysaci/sysweb/make4.go (ver 02) PXSY31L - listing of above files (16MAY2005 16:57) PXSY323 - File modification 16MAY2005 17:19 - sysaci/sysweb/make4.go (ver 02) PXSY323L - listing of above files (16MAY2005 17:19) Reference: Case 393203 Symptom: When using the "make4.go" file to link the Web Application Services Satellite Engine, the following error may occur: NLD: ERROR **** [1144]: NLD is halting due to the following fatal error: The file name '/usr/lib/cppinit.o' was specified on the command line, but this file does not exist. Problem: The A.C.I. "make4.go" file was based on a pre AAD version of the standard H.P. NSJ4 Java Makefile. Those versions included file cppinit.o, but it was removed when the AAD version was released. Some systems contain the cppinit.o file so no error is reported, other systems may not contain the cppinit.o file in which case the above error occurs. Change: Removed cppinit.o from the "make4.go" file. Since the minimum version of NSJ4 supported by A.C.I. is AAD, this matches the standard H.P. Jave Makefile for that version. Implementation: If using NET24-XPNET Web Application Services, perform the following steps to complete the installation of this scr. The sample commands are to aid in the discussion, actual commands may vary from site to site and should be executed with caution. 1) Restore the PXSY* files mentioned above to the XPNET Guardian subvolume. If the XPNET subvolume is on a virtual disk, copy the PXSY* files to a temporary subvolume on a non-virtual disk and use those in step 2. 2) Create a temporary OSS directory and use the OSS pax utility to restore the PXSY3 file to OSS. Restore the file applicable to the version of Tomcat your site is using (PXSY31 for Tomcat 3.1, PXSY323 for Tomcat 3.2.3). Example for a customer using Tomcat 3.2.3: > mkdir /user/temp > cd /user/temp /user/temp > pax -rvf /G//xpnet/pxsy323 # creates, overwrites /user/temp/sysaci/sysweb/* 3) Copy the make4.go file from the temporary directory to the installation directory. Save the existing make4.go file for reference in step 4. Example (save the old make4.go files): > mkdir /user/sysaci/sysweb/zzold > mv -i /user/sysaci/sysweb/make4.go \ /user/sysaci/sysweb/zzold Example (install the new make4.go file): > cp -p /user/temp/sysaci/sysweb/make4.go \ /user/sysaci/sysweb/. Other files were not changed, so those files are not re-installed. 4) If needed, customize the make4.go file for site specific variables. See the previous version of the file saved in step 3 above. 5) Make the sate executable object file. For example: > make4.go (builds an object file named sate) When making NSJ4 objects with make4.go, ignore warnings 10032 and 10034 (inconsistent floattype attributes). 6) Stop all satengine processes. 7) Copy the new sate object from step 5 to its runnable location. For example: > mv -i satengine old_sategine (rename old out) > mv -i sate satengine (rename new in) 8) Start satengine processes. 9) Purge temporary subvolumes and directories created in steps 1, 2, and 3. Dependencies: NSJ4 AAD. SCR #3306 CXUTIL - rel3^ver0^cxut02^060130 30-JAN-06 Reference: internal Symptom: CXUTIL was truncating some records as it was adding them to the EVENTCX file. Problem: The program requires that TPLS data be between columns 8 and 68 but does not generate any sort of error when data falls outside these columns. Change: Added error message that identify the problem and message number. Also coded to allow this program to run in batch mode: When running in batch these two assigns must be set: define =EVENTCX, file <$vol>..eventcx define =TEMPLATE_SOURCE, file <$vol>.. If these defines are present, CXUTIL will run in batch mode. Implementation: replace existing CXUTIL with this object. Dependencies: None SCR #3343 BASE - REL3^VER1^BASE^REL16^20061030 30-OCT-06 - REL3^VER1^AUD03^20061030 - REL3^VER1^DCOM06^20061030 - REL3^VER1^EXEC09^20061030 - REL3^VER1^GATE08^20061030 - REL3^VER1^MMGR04^20061030 - REL3^VER1^ONCF^CJ03^20061030 - REL3^VER1^ONCF^DEST05^20061030 - REL3^VER1^ONCF^LNK04^20061030 - REL3^VER1^ONCF^ONCF05^20061030 - REL3^VER1^ONCF^PRO09^20061030 - REL3^VER1^ONCF^STA06^20061030 - REL3^VER1^ONCF^SYS11^20061030 - REL3^VER1^PROC08^20061030 - REL3^VER1^QUE05^20061030 GLOBAL - n31glbl.glbl09tg DDLC - s31sddl.sddl04dc DDLCOB - s31sddl.sddl04dx DDLFUP - s31sddl.sddl04dz DDLS - s31sddl.sddl04ds DDLTAL - s31sddl.sddl04dt NCPDC - s31ncpi.ncpi08dc NCPDCOB - s31ncpi.ncpi08dx NCPDCB74 - s31ncpi.ncpi08dv NCPDDDL - s31ncpi.ncpi08ds NCPDFUP - s31ncpi.ncpi08dz NCPDTAL - s31ncpi.ncpi08dt NCPDTCL - s31ncpi.ncpi08da NETDDLS - n31glbl.gddl03ds NETDC - n31glbl.gddl03dc NETDTAL - n31glbl.gddl03dt NETDFUP - n31glbl.gddl03dz NETETCL - n31ems.ems07ea NETEC - n31ems.ems07ec NETEDDL - n31ems.ems07es NETETAL - n31ems.ems07et NETECOB - n31ems.ems07ex NETTPLO - n31ems.ems07po NETTPLS - n31ems.ems07ps NETADRD - rel3^ver1^audr04^20061031 NETCJRD - rel3^ver1^cjrp03^061030 rel3^ver1^rlbk01^20061030 NETDMPRD - rel3^ver1^dmqe04^20061030 NCPCOM - rel3^ver1^ncpc14^20061030 - rel3^ver1^ncpl12^20061030 - rel3^ver1^rlbk01^20061030 SVNCPI - rel3^ver1^rel14^20061030 - rel3^ver1^ncp12^20061030 - rel3^ver1^obj09^20061030 - rel3^ver1^rn08^20061030 SVNCS - rel3^ver1^sncs12^20061030 - rel3^ver1^ncpl12^20061030 - rel3^ver1^rlbk01^20061030 SVNCSP - svncsp-31-06 - svtab-a-31-05 NCSPRPT - ncsp-report-rel31-05 SVNCSP24 - svncsp-net24-31-06 - svtab-a-31-05 NLIB - rel3_ver1_nlib12_060721 NLIBDC - n30nlib.nlib05dc NLIBDCOB - n30nlib.nlib05dx NLIBDDDL - n30nlib.nlib05ds NLIBDTAL - n30nlib.nlib05dt NLIBEXTC - n31nlib.nlib12ce NLIBEXTS - n31nlib.nlib12te HTTPLIB - rel3_ver1_http10_061030 - rel3_ver1_http_util06_061030 HTTPDC - u31http.http03dc HTTPDCOB - u31http.http03dx HTTPDTAL - u31http.http03dt HTTPDDDL - u31http.http03ds MHDRLIB - rel3_ver1_mhdr10_061030 MHDRCEXT - n31mhdr.mhdr10ce MHDRTEXT - n31mhdr.mhdr10te PAYLLIB - rel3_ver1_payl_rel06_061030 - rel3_ver1_payl04_061030 PAYLCEXT - n31payl.payl04ce WGI - rel3^ver1^wgi04^20061030 PXSY31 - File modification 15DEC2006 21:14 - sysaci/sysweb/sate.o (ver 10) PXSY31L - listing of above files (15DEC2006 21:14) PXSY323 - File modification 15DEC2006 20:55 - sysaci/sysweb/sate.o (ver 10) PXSY323L - listing of above files (15DEC2006 20:55) XNLIB.XNLIB - REL3_VER1_XNLIB_REL20_060801 - REL3_VER1_NLIB12_060721 - REL3_VER1_MHDR10_061030 - REL3_VER1_HTTP10_061030 - REL3_VER1_HTTP_UTIL06_061030 - REL3_VER1_PAYL_REL06_061030 - REL3_VER1_PAYL04_061030 XNLIB.XNLIBN - (same mods as XNLIB.XNLIB) XNLIB.XNLIBR - (same mods as XNLIB.XNLIB) XNLIB.XNLIBEN - (same mods as XNLIB.XNLIB) XNLIB.XNLIBER - (same mods as XNLIB.XNLIB)01 XNLIB.XNDC - n31nlib.nlib05dc - u31http.http03dc XNLIB.XNDCOB - n31nlib.nlib05dx - u31http.http03dx XNLIB.XNDTAL - n31nlib.nlib05dt - u31http.http03dt XNLIB.XNCEXT - n31nlib.nlib12ce - n31mhdr.mhdr10ce XNLIB.XNCEXT - n31nlib.nlib12te - n31mhdr.mhdr10te Reference: Large Message Support Enhancement Symptom: None. Problem: None. Change: Modified XPNET to support large multi-chunk messages routed between processes and selected communications protocols. With this enhancement the maximum message size supported will be increased significantly (10MB will be allowed). Implementation: NOTE: If application processes need to support large messages as implemented with this enhancement, application code changes will be required (see notes below). Note that the SKELB API will not support large messages, only the XNLIB API. Install the new XPNET files on the XPNET subvolume. Install the new XNLIB files on the XNLIB subvolume. On the XPNET subvolume, rebuild the NETWORK object using the NETBC obey file. If the customer uses the APPLIB library, it should be rebuilt using the APPLIBBC and APPLIBB files to include the modified HTTPLIB, MHDRLIB and PAYLLIB libraries. Follow the directions in APPLIBB for completing this process. The resulting APPLIB object can be renamed to SKELB if desired. If on a MIPS RISC machine (S-Series), accelerate the objects as shown in the XPNET.NETAXCL file. APPLIB may also be accelerated separately by obeying the APPLAXCL file. The non-native XNLIB library object can be accelerated using the XNLIB.XNAXCL obey file. If using an Itanium NonStop machine (NS-Series), accelerate appropriate files using the following OCA macros: - XPNET.OCAAPPL (for XPNET.APPLIB, if rebuilt) - XPNET.OCANCPI (for XPNET.SVNCPI) - XPNET.OCANETAD (for XPNET.NETADRD) - XPNET.OCANLIB (for XPNET.NETLIB) - XNLIB.OCAXNLIB (for XNLIB.XNLIB) Application processes which use SKELB, XNLIB or XNLIBN as a run-time library must be stopped and restarted in order for the new library to take effect. Application processes which bind one of the above libraries must be re-compiled or re-bound with the new library. Re-install all EMS templates using the SCRIBE.GOINST macro. Stop and restart all XPNET nodes. Stop all the NCPI servers from TACL. Freeze/Stop/Thaw all active SVNCS, SVNCSP servers from Pathway. If security is enabled, update the approriate NCSP records to allow access for the new NODE MAXLARGEMSGSIZE attribute. If Large Message Support is going to be used (i.e. if you have a requirement to route messages larger than 32000 bytes through your XPNET system, or messages larger than 18000 bytes without multi-message checkpointing being performed), alter the new NODE MAXLARGEMSGSIZE attribute to indicate the maximum allowable message size (bytes) that is to be supported. By default, no action is required to continue without large message support. If using NET24-XPNET Web Application Services (Satengine) perform the following steps to install and use the new Satengine code. The sample commands are to aid in the discussion, actual commands may vary from site to site and should be executed with caution. 1) Restore the PXSY* files mentioned above to the XPNET Guardian subvolume. If the XPNET subvolume is on a virtual disk, copy the PXSY* files to a temporary subvolume on a non-virtual disk and use those in step 2. 2) Create a temporary OSS directory and use the OSS pax utility to restore the PXSY3 file to OSS. Restore the file applicable to the version of Tomcat your site is using (PXSY31 for Tomcat 3.1, PXSY323 for Tomcat 3.2.3). Example for a customer using Tomcat 3.2.3: > mkdir /user/temp > cd /user/temp /user/temp > pax -rvf /G//xpnet/pxsy323 # creates, overwrites /user/temp/sysaci/sysweb/* 3) If installing on a S-Series NonStop system (non- Itanium) copy the 'sate.o' file from the temporary directory to the installation directory. If installing on an Itanium NS-Series NonStop system, copy the 'satengine' file from the temporary directory to the installation directory. Example (save the old sate.o file): > mkdir /user/sysaci/sysweb/zzold > mv -i /user/sysaci/sysweb/sate.o \ /user/sysaci/sysweb/zzold Example (install the new sate.o file): > cp -p /user/temp/sysaci/sysweb/sate.o \ /user/sysaci/sysweb/. Other files were not changed, so those files are not re-installed. 4) If installing on an S-Series NonStop system (non- Itanium) make the sate executable object file. Use the appropriate make file for the NSJ version you are using. For example, if using NSJ4: > make4.go (builds an object file named sate) When making NSJ4 objects with make4.go, ignore warnings 10032 and 10034 (inconsistent floattype attributes). 5) Stop all satengine processes. 6) If installing on an S-Series NonStop system (non- Itanium) copy the new sate object from step 4 to its runnable location. For example: > mv -i satengine old_sategine (rename old out) > mv -i sate satengine (rename new in) If installing on an S-Series NonStop system (non- Itanium) use the 'satengine' file provided (see step 3) 7) Start satengine processes. 8) Purge temporary subvolumes and directories created in steps 1, 2 and 3. If an application process is going to send or recieve messages larger than 32000 bytes (or if messages larger than approximately 18000 bytes are being split into multiple chunks), the application will require code changes to implement the large message support added to the XNLIB API library. If messages less than 64K bytes in length are going to be supported, the changes are mainly to pass in several new parameters to the NETLIB_INIT procedure at application initialization. If messages larger than 64K bytes are required, further changes are required, mainly allowing the application to receive the chunks from the NODE and call the new XNLIB procedure NETLIB_RCV_LARGEMSG_CHUNK to piece the message together. Sending messages larger than 64K bytes will require the application to call the new NETLIB_SEND_LARGEMSG procedure. See further details as documented in the NET24-XPNET Application Programming Reference Manual (changes forthcoming). If large messages coming in through WGI stations from WebGate are larger than 18000 bytes and causing multi- message checkpoints to the XPNET backup process (the STATISTICS NODE, DETAIL command shows the number of multi-message checkpoints that have been peformed by the XPNET process) the DEVICE being used by the WGI stations can be altered to have an XMITLEN of 18000 bytes to elimiate the multi-message checkpoints. Dependencies: All of these changes must be implemented simultaneously or messaging problems may result. SCR #3381 BASE - REL3^VER1^PROC09^20070122 22-JAN-07 - REL3^VER1^BASE^REL17^20070122 BASE - rel3^ver0^proc38^070122 - rel3^ver0^rel70^070122 GLOBAL - N31GLBL.GLBL10TG GLOBAL - n30glbl.glbl38tg Reference: Case 418892 Symptom: All available payload memory has been used, and the following events are logged. 07-01-22;11:43:29.144 \X.$P1AN ACI.XPNET.3000 6361 Unable to save payload in memory, all payload memory has been used. NODE PAYLOADPAGES must be increased. 07-01-22;11:43:29.146 \X.$P1AN ACI.XPNET.3000 6357 Error with payload in MSG sent to Process P1A^AUTH. The payload could not be saved in memory for this MSG. Problem: If an application that allows XPNET to manage payload replies to a message with no data, the payload being held by XPNET for that message is not released. Increasing the NODE PAYLOADPAGES and/or decreasing the NODE PAYLOADTIMEOUT MAY provide a temporary work around. The particular problem reported by this case happened because de-SAF processing flooded the Auth process with messages. Classic Auth does not manage payload, so XPNET manages it on Auth's behalf. Change: Changed XPNET to release any payload being held for a message when an application replies to that message with no data. SKEL and NETLIB will reply with no data on the users behalf when the next read is done if the application has not sent a reply. Implementation: Install the new files on XPNET subvol. Rebuild the NETWORK object using the NETB file. If installing XPNET 3.0 on a MIPS RISC machine (S-Series), accelerate the objects as shown in the XPNET.NETAXCL file. If installing XPNET 3.0 on an Itanium machine (NS-Series), accelerate the objects using the following OCA macros: - XPNET.OCANET (for XPNET.NETWORK) On the SCRIBE subvol, obey TMPLMAKE to rebuild the TMPLNRES and TMPLRES files, and then obey GOINST to rebuild the complete template set. Next run CXUTIL. Refer to section EMS Template Installation Steps in the BASE24-XPNET 3.x Implementation Guide for details on the above steps. Restart EMS distributors with the new EMS Template file that is produced. Dependencies: None. SCR #3403 SATEPLO - W11SATE.SATE05PO 30-May-07 SATEPLS - W11SATE.SATE05PS ---OSS WAX 1.1 MIPS version (installed on XPNET subvol) PXSY31 - EOF 286208 06SEP2007 14:35 sysaci/sysweb/sate.o T0000D45_30MAY07_WAX11_SATE11 PXSY31L - EOF 1131 06SEP2007 14:35 listing of above files PXSY323 - EOF 298496 06SEP2007 14:59 sysaci/sysweb/sate.o T0000D45_30MAY07_WAX11_SATE11 PXSY323L - EOF 1131 06SEP2007 14:59 listing of above files ---OSS WAX 1.1 ITANIUM version (installed on XPNET subvol) PXSY31 - EOF 292864 06SEP2007 14:35 sysaci/sysweb/satengine T0000D45_30MAY07_WAX11_SATE11 PXSY31L - EOF 496 06SEP2007 14:35 listing of above files PXSY323 - EOF 305152 06SEP2007 14:59 sysaci/sysweb/satengine T0000D45_30MAY07_WAX11_SATE11 PXSY323L - EOF 496 06SEP2007 14:59 listing of above files Reference: Case 435114. Symptom: A Satengine process logs the following message and abends. 07-05-30;15:26:13.382 \SYS.$PPD ACI.XPSATE.3000 2 Servlet Engine is abnormally terminating (caller 150). Problem: SCR3343 (the large message scr) changed some buffer sizes leaving one buffer larger than another. This caused a buffer overrun when the larger was moved to the smaller, and variables on the stack were corrupted as a result. Change: Changed the size of buffers to be in sync with each other. Implementation: Install the new files on XPNET subvol. On the SCRIBE subvol, obey TMPLMAKE to rebuild the TMPLNRES and TMPLRES files, and then obey GOINST to rebuild the complete template set. Next run CXUTIL. Refer to section EMS Template Installation Steps in the BASE24-XPNET 3.x Implementation Guide for details on the above steps. Restart EMS distributors with the new EMS Template file that is produced. Perform the following steps to complete the installation of the new Satengine object: 1) Restore the PX* files mentioned above to a subvolume on a non-virtual disk volume. 2) Create a temporary OSS directory and use the OSS pax utility to restore the PXSY3 file to OSS. Restore the file applicable to the version of Tomcat your site is using (PXSY31 for Tomcat 3.1, PXSY323 for Tomcat 3.2.3). Example for a customer using Tomcat 3.2.3: > mkdir /user/temp > cd /user/temp /user/temp > pax -rvf /G//xpnet/pxsy323 # creates, overwrites /user/temp/sysaci/sysweb/* 3a) If installing on a S-Series system (non-Itanium), follow the instructions below. If installing on a NS-Series (Itanium), skip to step 3b. copy the 'sate.o' file from the temporary directory to the installation directory. Example (save the old sate.o file): > mkdir /user/sysaci/sysweb/zzold > mv -i /user/sysaci/sysweb/sate.o \ /user/sysaci/sysweb/zzold Example (install the new sate.o file): > cp -p /user/temp/sysaci/sysweb/sate.o \ /user/sysaci/sysweb/. Other files were not changed, so those files are not re-installed. Make the sate executable object file. Execute the appropriate make file for the NSJ version you are using. For example, if using NSJ4: > cd /user/sysaci/sysweb > make4.go (builds an object file named sate) When making NSJ4 objects with make4.go, ignore warnings 10032 and 10034 (inconsistent floattype attributes). Stop any running Satengine processes. Copy the sate object file to its runnable location: > mv -i satengine zzold (renames old satengine) > cp -p sate satengine Restart Satengine processes. 3b) If installing on NS-Series (Itanium), follow the instructions below. Stop any running Satengine processes. Copy the 'satengine' file from the temporary directory to the installation directory. Example (save the old satengine file): > mkdir /user/sysaci/sysweb/zzold > mv -i /user/sysaci/sysweb/satengine \ /user/sysaci/sysweb/zzold Example (install the new satengine file): > cp -p /user/temp/sysaci/sysweb/satengine \ /user/sysaci/sysweb/. Other files were not changed, so those files are not re-installed. Restart Satengine processes. Dependencies: None. SCR #3405 BASE - REL3^VER1^PROC09^20070122 30-MAY-07 - REL3^VER1^BASE^REL17^20070122 BASE - rel3^ver0^proc38^070122 - rel3^ver0^rel70^070122 GLOBAL - N31GLBL.GLBL10TG GLOBAL - n30glbl.glbl38tg NETEC - N31EMS.EMS08EC NETECOB - N31EMS.EMS08EX NETEDDL - N31EMS.EMS08ES NETETAL - N31EMS.EMS08ET NETETCL - N31EMS.EMS08EA NETTPLO - N31EMS.EMS09PO NETTPLS - N31EMS.EMS09PS NETEC - n30ems.ems27ec NETECOB - n30ems.ems27ex NETEDDL - n30ems.ems27es NETETAL - n30ems.ems27et NETETCL - n30ems.ems27ea NETTPLO - n30ems.ems33po NETTPLS - n30ems.ems33ps SATEPLO - W11SATE.SATE05PO SATEPLS - W11SATE.SATE05PS ---OSS WAX 1.1 MIPS version (installed on XPNET subvol) PXSY31 - EOF 286208 06SEP2007 14:35 sysaci/sysweb/sate.o T0000D45_30MAY07_WAX11_SATE11 PXSY31L - EOF 1131 06SEP2007 14:35 listing of above files PXSY323 - EOF 298496 06SEP2007 14:59 sysaci/sysweb/sate.o T0000D45_30MAY07_WAX11_SATE11 PXSY323L - EOF 1131 06SEP2007 14:59 listing of above files ---OSS WAX 1.1 ITANIUM version (installed on XPNET subvol) PXSY31 - EOF 292864 06SEP2007 14:35 sysaci/sysweb/satengine T0000D45_30MAY07_WAX11_SATE11 PXSY31L - EOF 496 06SEP2007 14:35 listing of above files PXSY323 - EOF 305152 06SEP2007 14:59 sysaci/sysweb/satengine T0000D45_30MAY07_WAX11_SATE11 PXSY323L - EOF 496 06SEP2007 14:59 listing of above files Reference: Case 436425. Symptom: XPNET 3.0 logs the following message when a Satengine process is started, and the Satengine process abends. 07-06-15;12:00:45.129 \SYS.$PPD ACI.XPNET.3000 6070 Process unknown setmode function 107 (0,-2) Problem: SCR3343 (the large message scr) added a setmode call from XNLIB to XPNET if the process supports large messages. The Satengine process was enhanced to support large messages, so XNLIB issued the new setmode on behalf of the Satengine. Since large message support was only added to XPNET 3.1, an error 2 is returned to the setmode when using XPNET 3.0 Change: Changed the Satengine so it implements large message support only if the XPNET that started it supports large messages. Also changed the Satengine to vary the size of output messages depending on the release of XPNET and whether it is configured for warm or hot backup (to eliminate multi-message checkpoints in XPNET regardless of the configuration). If the backup type is altered while the Satengine is running, the Satengine must be stopped and re-started (whether an XPNET backup is running or not doesn't change the calculation, so that never matters). Maximum output message segment size: Warm backup (all releases) : 32,000 bytes Hot backup (3.0 and older): 11,000 bytes Hot backup (3.1 and newer): 18,000 bytes Changes were made to XPNET to return the above values. If a version of XPNET is running that doesn't include these changes, or an error occurs on the attempt to retrieve them, the Satengine defaults to "no large message support" and to a max output message segment of 11,000 bytes. Satengine log event #1 was enhanced to log the values obtained from XPNET. Implementation: Install the new files on XPNET subvol. Rebuild the NETWORK object using the NETB file. If installing XPNET 3.0 on a MIPS RISC machine (S-Series), accelerate the objects as shown in the XPNET.NETAXCL file. If installing XPNET 3.0 on an Itanium machine (NS-Series), accelerate the objects using the following OCA macros: - XPNET.OCANET (for XPNET.NETWORK) On the SCRIBE subvol, obey TMPLMAKE to rebuild the TMPLNRES and TMPLRES files, and then obey GOINST to rebuild the complete template set. Next run CXUTIL. Refer to section EMS Template Installation Steps in the BASE24-XPNET 3.x Implementation Guide for details on the above steps. Restart EMS distributors with the new EMS Template file that is produced. Perform the following steps to complete the installation of the new Satengine object: 1) Restore the PX* files mentioned above to a subvolume on a non-virtual disk volume. 2) Create a temporary OSS directory and use the OSS pax utility to restore the PXSY3 file to OSS. Restore the file applicable to the version of Tomcat your site is using (PXSY31 for Tomcat 3.1, PXSY323 for Tomcat 3.2.3). Example for a customer using Tomcat 3.2.3: > mkdir /user/temp > cd /user/temp /user/temp > pax -rvf /G//xpnet/pxsy323 # creates, overwrites /user/temp/sysaci/sysweb/* 3a) If installing on a S-Series system (non-Itanium), follow the instructions below. If installing on a NS-Series (Itanium), skip to step 3b. copy the 'sate.o' file from the temporary directory to the installation directory. Example (save the old sate.o file): > mkdir /user/sysaci/sysweb/zzold > mv -i /user/sysaci/sysweb/sate.o \ /user/sysaci/sysweb/zzold Example (install the new sate.o file): > cp -p /user/temp/sysaci/sysweb/sate.o \ /user/sysaci/sysweb/. Other files were not changed, so those files are not re-installed. Make the sate executable object file. Execute the appropriate make file for the NSJ version you are using. For example, if using NSJ4: > cd /user/sysaci/sysweb > make4.go (builds an object file named sate) When making NSJ4 objects with make4.go, ignore warnings 10032 and 10034 (inconsistent floattype attributes). Stop any running Satengine processes. Copy the sate object file to its runnable location: > mv -i satengine zzold (renames old satengine) > cp -p sate satengine Restart Satengine processes. 3b) If installing on NS-Series (Itanium), follow the instructions below. Stop any running Satengine processes. Copy the 'satengine' file from the temporary directory to the installation directory. Example (save the old satengine file): > mkdir /user/sysaci/sysweb/zzold > mv -i /user/sysaci/sysweb/satengine \ /user/sysaci/sysweb/zzold Example (install the new satengine file): > cp -p /user/temp/sysaci/sysweb/satengine \ /user/sysaci/sysweb/. Other files were not changed, so those files are not re-installed. Restart Satengine processes. Dependencies: None.